今天就來談談我的老本行「軟體開發」的控制措施吧，軟體開發可是資訊技術中與硬體平起平坐的生產單位，由於不像硬體是有形 (tangible) 的資產，為妥善且有效的管控這個無形 (intangible) 的資產，自然會施加的控制措施相對較多。

一個完整的軟體開發生命週期 (Software Development Lifecycle, SDLC)，由一開始的需求分析、系統分析、系統設計、系統開發，乃至於系統測試與最後的部署維護，每個環節基本上都和資訊脫不了關係，軟體開發的每個時刻都在生產著資訊，尤其又以將軟體開發視為核心業務的產業來說，處處都是「有價值的事物」，即便不是以軟體開發為業，在軟體上經營組織的事業，自然也會產生相當多「有價值的事物」，而且軟體並不像硬體會嗶嗶叫或有信號提示燈來給予提示，很多風險其實會在開發與使用軟體的過程中不自覺的發生，所以在軟體的生產過程中要投以更多的關注，以確保軟體的開發過程中維持著一定程度的安全。

在前一版的ISO 27001:2013中，軟體開發相關的控制措施被稱為「系統獲取、開發與維護」，共分為三個主題，分別是資訊系統之安全要求事項 (A.14.1)、於開發及支援過程中之安全 (A.14.2) 以及測試資料 (A.14.3)，共列出了13項控制措施；不過到了ISO 27001:2022，軟體開發的控制措施被揉合為8項控制措施，分別為A.8.25~A.8.31及A.8.33，雖然控制措施的數量減少了，但範圍反而變得更大了，因為引進了安全開發生命週期 (A.8.25) 這個控制措施。

安全軟體開發生命週期 (Secure SDLC, SSDLC) 源自微軟於2004年為強化自身軟體產品安全所開發的安全開發生命週期 (Security Development Lifecycle, SDL)，它強調了軟體開發在各階段中應進行的7項資訊安全活動：

1. 訓練 (Training)：教育員工資訊安全認知、概念、技術與趨勢。
2. 需求 (Requirements)：分析與定義產品的資訊安全需求。
3. 設計 (Design)：針對需求進行設計，其中包含威脅建模 (Threat Modeling) 以辨識可能的風險加以因應。
4. 實作 (Implementation)：以符合安全的規範進行軟體開發，並提供必要的支援工具。
5. 驗證 (Verification)：在軟體發行前必須經過數個關卡的檢驗，其中會包含靜態原始碼分析、動態系統弱點測試、功能測試、滲透測試、組態驗證以及元件管制等，確保軟體程式碼符合安全與品質規範。
6. 發行 (Release)：利用數個發行通道 (release channels) 由內部逐步擴及到外部的發行作法，以及早確認發行是否會產生問題。
7. 回應 (Response)：軟體內會加入許多蒐集數據與監控的機制，以識別可能的安全性事件並及時進行回應。

後來SSDLC逐步的由ISO制定為ISO 27034應用程式安全的標準家族，包含組織規範框架 (Organizational Normative Framework)、應用程式安全控制措施 (Application Security Control) 等相關標準。

雖然一般的組織不太可能有像微軟這麼龐大的資源能實作如此巨大的框架，但SSDLC的精神可以適當的納入軟體開發的過程中：

基本上，ISO 27001:2022的8個控制措施以SSDLC為核心串接起來，組織只要有落實SSDLC，自然會一併落實另外7個控制措施，當然，組織的軟體開發過程也必須要實作那7個控制措施，以滿足SSDLC這個控制措施的要求；在SSDLC的各個階段，組織可導入自動化機制來自動執行相關工作，例如CI/CD以及DevOps整合安全 (亦即DevSecOps) 的自動機制，減少可能的人為失誤並產生相關的驗證記錄，作為後續確認相關控制措施的執行證據。